Schedule

Welcome words

Registration

Break

Longer break

Lunch break

Closing words

Virtual Doors Open

Breakout Sessions

Networking time

Registration

Opening Keynote

Closing Keynote

schedgroup: a Timer-Based Goroutine Concurrency Primitive

Go provides first-class support for concurrency primitives such as goroutines, channels, and select statements. In addition, the Go runtime provides excellent support for high-resolution timers. By combining these primitives, we can create powerful new ones that take advantage of Go’s concurrency and runtime timer facilities.

This talk will introduce a timer-based concurrency primitive called a “schedgroup”: short for “scheduler group”. The schedgroup.Group API mimics the familiar and simple sync.WaitGroup from Go’s standard library. The key feature of the schedgroup.Group type is its ability to efficiently delay or schedule the execution of goroutines according to user-specified time values.

While prototyping the schedgroup package, several different designs were explored, each with differing advantages and disadvantages:

• a minimal implementation which creates a timer per goroutine for scheduling tasks
• a timer-polling approach which checks for scheduled tasks in a queue at a fixed interval
• an event-driven scheduler approach which uses a priority queue and signaling with channels

This talk will demonstrate the strengths and weaknesses of each prototype, building on top of each previous iteration until we reach the final design and implementation of the package as it stands today. During the presentation, attendees will learn about concepts related to Go concurrency and runtime timers, including:

• blocking and non-blocking channel send/receive operations within a select statement
• patterns for implementing context cancelation in concurrent systems
• troubleshooting and prevention of goroutine deadlocks
• efficient use of Go’s time.Timer APIs for tracking elapsed time during operations
• implementing a time-based priority queue with Go’s container/heap package

Talk 3

Talk 4

Talk 5

Talk 6

Talk

Error handling and Pitfalls in Distributed Go Applications

CockroachDB has seen a relatively large amount of bugs in 2018-2019 due to improper error handling, in turn stemming from Go’s “idioms” (community recommendations). Close inspection has revealed that previous Go best practices turn into outright bugs and code complexity when the code is distributed and error handling spans a network. The various problems have been identified in the CockroachDB RFC here. The talk will summarize the main findings and generalize them to other Go projects beyond CockroachDB, as well as present the general design directions behind the general-purpose ‘errors’ library aiming to become a drop-in replacement to Go’s standard errors package in distributed Go apps.

Lightning Talks

Go Developer Network: Better Together

Just over one year ago, we launched the Go Developer Network which now has over 100,000 members. The initial growth of the GDN has been exciting to see. For me personally, it is even more exciting to see the connection and support between many of the GDN participants. We have all heard that the whole is greater than the sum of the parts. When I reflect back on the GDN collaboration for Go’s 10th Birthday, I can see that is true. Additionally, the relationships forged through this collaboration make the parts greater too. You’ll walk away from this talk with an understanding of how the GDN makes us better together both as a global developer community and as individuals. For those of you not already involved, you’ll learn how you can join us!

Field Report: Building a game engine for 300 defcon hackers to smash

We wanted to host an event we had not seen before: a narrative-driven capture-the-flag (CTF) game that would immerse the players in it’s story. Since no platform existed that would facilitate the kind of direct, ongoing player interactions we wanted, we set out to build our own game engine.

We created a platform that enabled players to receive game information, objectives, hints, and scoring, from a semi-automated/interactive entity known as their “Handler”.But these were no ordinary players: with our booth at DEFCON 26 and a $10,000 grand prize on the line, we had 300+ of the best hackers on the planet motivated to beat our game however they could. This is the story of how we built the game engine that would bring the vision to life, and lessons learned from surviving the onslaught.

Error handling and Pitfalls in Distributed Go Applications

More than five years ago, sync.Pool was added to Go’s standard library to help gophers alleviate the pressure on the Garbage Collector by providing a convenient way to reduce allocations. Since then, many have adopted it and multiple talks and posts have been written about the topic.

In this talk, we go into a slightly deeper dive than usual with a mischievous mindset. The implementation of sync.Pool benefits from a tight coupling with the Go runtime. Let’s explore some unexpected ways in which we could benefit from sync.Pool special place in the Go ecosystem

Work with the language, not against it: Case studies in concurrency design

Like many projects written in Go, [redacted open source project] is highly concurrent. And like all such applications, we’ve faced challenges when writing highly concurrent code that is correct, performant, and readable.

The talk begins by touching on the relevant aspects of the Go language. What tools does a Go programmer have to write concurrent code? What role does the Go runtime play in concurrency? With these ideas in mind, the talk then examines a few early designs from [redacted] against their refactored improvements, using each as a case study of concurrency dos and don’ts. Attendees will leave with specific lessons that will improve their concurrent designs, backed by memorable, concrete examples of those lessons in practice.

Why you shouldn't write your own memory management in Go

The metrics database we work on - Metrictank - powers Grafana Cloud and is also deployed at customer’s premises. In some of these deployments, resource utilisation affects the bottom line. Last year, we kicked off an ambitious project with the main goal of cutting into memory usage and also reducing GC overhead. We would achieve this by managing our own slabs of memory outside the GC’s reach and storing a certain class of strings there in de-duplicated form. Despite the promising idea and the diligent execution, we had not fully considered all trade-offs, which led to the project failing. Instead of reduced memory and infrastructure bills, we’re left with many lessons learned, a handful of interesting open source libraries, an increased appreciation for the GC, and some brewing ideas for revisiting this effort. In this talk, you will learn about all of this.

Practical fuzzing in Go

Fuzzing is a commonly used technique among security engineers to find bugs and vulnerabilities in code. Its effectiveness has been proven over time to the point where some projects and companies have mandatory fuzzing coverage. The most common issue with fuzzing is that it is seen as a low-level arcane practice that does not apply to memory safe languages or that only hackers can use.With this session I will explain what fuzzing is, why it is useful and how to apply it to your code. I will provide detailed instructions and examples to get the attendees up and running to make their code more robust, correct and trustworthy.

Going Driverless at Einride: How We Developed a CAN Library for Go

On May 15th 2019, Einride’s Pod become the first cab-less electric truck to drive on a public road. A surprising amount of software running in this vehicle is written in Go.

I will give the audience a look into the software development of a driverless vehicle, and how Go can be applied to great success. The talk centers around a key problem we had to overcome at Einride to use Go for vehicle software development, namely CAN communication. I'll showcase the Open Source library we developed (https://pkg.go.dev/go.einride.tech/can) and share some learnings on leveraging the standard library, the runtime poller, and a code generator inspired by protocol buffers and gRPC.

The audience will walk away knowing more about driverless vehicles, the CAN protocol, the CAN-Go library, and an experience report from applying Go to a new domain.

Gopls for Go Tooling

You have had challenges with your development tools being inefficient and slowing you down. In this session, we will cover how we ended up in this situation and the promising future Gopls is working toward to enable higher productivity

We’ll look at the recent history of tools we have been using in Go development and the challenges we faced with them. We will then look at how Gopls is designed and why it is worth exploring.

A journey to Postgres Productivity with Go

We will begin our journey by taking a look at a few different reasons why you would want to use a persistent data store, a relational database, and finally why you should just use Postgres most of the time. Having established what it’s used for, we will begin looking at the myriad of ways that the Go community has developed for working with databases, and Postgres in particular.

Socket to Me: Where do Sockets Live in Go?

This tutorial will explore sockets, an example of the interface between Go’s high-level simplicity and the low-level functionality the language offers. Specifically, attendees will delve into the fundamentals of sockets and socket configuration in Go, then learn where this low-level knowledge can be useful to Gophers.

Socket-level networking calls–like bind()–are abstracted away in the Go net package. Instead, they are handled by Listener functions for TCP and UDP. If Go is a programmer’s first brush with level 4 networking, they may write TCP and UDP code without ever knowing what sockets are! There are cases, however, where knowing what a socket is becomes extremely useful for practical Go applications. One such case is when exclusively binding a socket to a port is too coarse. For example, an engineer supporting a TLS1.2 stack while stress-testing a new TLS1.3 draft implementation would need both TLS handlers to share port 443. In this case, multiple process sockets seek to share the same port–a construction not possible when calling Go’s TCP and UDP listener functions out of the box. Socket knowledge becomes invaluable in this situation.

Namely, knowing about socket options is crucial for assigning specific behavior to a ports, such as the ability to have multiple processes listen on one port at once. Socket options prove useful for a variety of networking projects; for instance, the TLS example above calls for SO_REUSEADDR, a socket option that allows multiple processes to use the same port. When I found myself needing to pass SO_REUSEADDR to a UDP socket, I learned that passing socket options in Go is a nontrivial task–one that spans the net and golang.org/x/sys packages! I will demonstrate how these packages came together to expose the sockets and socket options I needed for my work.

I’m excited to share what I’ve learned about socket programming in Go and demonstrate where this low-level knowledge is useful. I found using sockets in Go surprisingly more involved than using them in other languages from C to Python, and hope to make socket option usage patterns less intimidating for Go programmers.

Though this talk is aimed towards novice systems-oriented Gophers, I will provide a brief overview of UDP and TCP sockets, as well as socket options folks are likely to encounter. To contextualize my talk, I’ll dive into a story about how I found myself in a position where I needed to use the SO_REUSEADDR socket option. I’ll walk through the code necessary for configuring TCP or UDP sockets, and demonstrate its interdependence between the net and golang.org/x/sys packages. Finally, I’ll explain how this experience helped me see through the eyes of a Go maintainer, and embrace the logic underlying Go’s unique socket abstractions. This tutorial seeks to be an explanation of one case of low-level programming in Go, and why I think Go is correct in abstracting away sockets and socket options more than other languages.

Learning Go Pointers Through C

When looking at the total population of engineers across all languages, the vast majority have no idea how pointers work and are afraid of them. Stories are often told about the nightmares of null pointers and how challenging it is to manage our own memory. Go took these challenges and created a type that is incredibly powerful and type-safe. This is wonderful if you have used pointers previously, but might not mean much to you if you have never used or understood pointers before. In fact, the best way to understand pointers is not to learn them in Go, but to learn them in C, our programming predecessor. This talk will dive deep into the details, uses, and problems of C pointers, so that we can appreciate and understand why the Go language is the way that it is. Then it will cover the details of Go pointers and how we can powerfully and safely use them, so that you can walk away confidently using them in your own services.

Using Interfaces in Go

Most people find it difficult to fully grasp the concept of interfaces in golang and how powerful they can be, because the way interfaces are thought to newcomers in Golang is fundamentally flawed. Most people who pickup golang do so from some other languages and extrapolate knowledge of what interfaces are from there, when in actual fact, the concept of interfaces in these two couldn't be any more different. This talk will touch upon how interfaces are particularly different from interfaces in other languages, how that makes it more powerful and how they can be used to build better services simply by understanding the concept behind interfaces.

Pie to Go: Automatically Translating Python Source to Idiomatic Go Code

Manually converting source code in one language to another is laborious. Existing approaches, often dubbed “transpilers” the JavaScript community, are insufficient for this purpose as they (1) produce code intended for machines, not humans; (2) work in the direction of going from stronger type systems to equivalent or weaker type systems.

This talk presents an approach that addresses both of these concerns. I will present how we successfully converted a project of several thousand lines of dynamically typed Python code into human-readable, fully typed, idiomatic Go source code. The program is built entirely in Go and consists of a Python parser, a static analyzer that does full-program analysis to understand what type(s) each Python object may be, and an output stage that converts this representation into idiomatic Go code.

The talk will show the audience how the program works and how to overcome the challenges of going from dynamically typed Python source code to fully typed Go source code. It will give the audience a better understanding of parsing source code into ASTs, how to analyze them and rewrite them to perform modifications, and lastly how to use Go’s excellent source code formatting to output properly formatted Go source code at the end.

Come for the Language. Stay for the People

Communities exist for all sorts of things. It may be a sports club, a religious group, a political group, or a social activity. A community can be around a shared interest, or shared desire to learn something new. A community can be location specific or spread around the globe. The Go community is a number of these; it is spread around the globe, with strong local representation. It is forged around a shared interest and a desire to learn. But what makes a community successful? Thinking about a traditional village community, the sort I grew up in, we will consider what makes those communities thrive and become desirable places to live and then apply those lessons to the Go community and see what we can learn. The aim here is to realise that we can all be Go community contributors and we all have a responsibility for the community and its success.

A Young Lady's Illustrated Primer to Technical Decision-Making

Over the last few years we’ve seen an explosion of complexity, in everything from polyglot storage to composable infrastructure, containerization and microservices, config management vs immutable infrastructure. Until recently there was a set of widely accepted best practices for running in the cloud. But now every element of your stack is a never-ending rabbit hole of possibilities and questions. What’s an engineer or architect or manager to do? And where does golang fit in??

Solid technical judgment is more important than ever. You can’t anticipate every problem, but you can identify and head off many of them in advance. We’ll talk about how to identify and prioritize where to be boring and where to innovate; how to choose a language based on use case; when to rewrite and when to double down; how to select a golden path of technology that will scale as your team does … and how to correct course when you’ve made a wrong call.

Digging through the Go Repository

Did you know that the first commit in Go repository was done in 1972? Did you know that Go repository once contained the Spacewar!, the original PDP-1 video game? Did you know that there also was the standard Go interpreter and debugger, and channels once worked across a network? Come to my talk to learn more fun and nerdy facts about Go pre-Go1 language, standard library, and tooling history.

How to Structure Your Microservices

Most of us have been happily writing monoliths for years, then not so happily struggled to refactor those as they grew. Then we heard the magic word: microservices.

But what exactly are they? How small should a microservice be? And are they really that good?

There are definitely pros and cons to this approach, and unfortunately many people seem to have had a pretty bad experience overall. Microservices are not easy to get right. But it is possible, and I want to show you how.

When I was considering my next career move back in 2018, I wanted to work for a company which does microservices well. Building a fully-licensed bank with over 3 million customers, written entirely in Go, using over 1500 microservices with 99.999% uptime seemed like a decent enough challenge. If you can make that work, and get the regulators and customers to trust you with their money, you must be doing something right. I wanted to know the secret sauce.

So this talk is about the lessons I’ve learnt so far on how to design microservices well and make them work for the team, at scale. I’ll talk about the key rules to follow and how to break down problems into the right set of individual services. We’ll walk through designing and implementing a simple API endpoint using microservices to demonstrate how to build small, consistent, understandable and extensible services which together form a powerful and resilient system.

The point is not to say that microservices are better or worse than monoliths. The point is to show a set of best practices for building successful microservice architectures, based on my experience. We’ll talk about:

• the benefits of having homogenous services, with example structures
• deciding when something should be in its own microservice
• orchestrating and testing microservices
• designing with typical networking and reliability issues in mind
• safely introducing changes affecting multiple services with no downtime
• code ownership and allowing large teams to make changes safely and independently
• designing extensible, not flexible systems which grow and scale well over time

A Tale of Breadth-First Search

One of my passions is optimizing different algorithms. It might seem that those fancy fast algorithms you see are a spark of imagination and “just happen”. In practice, the way you get to them is much more incremental. For every good idea, there are at least five that failed.

One fundamental way of optimizing algorithms is:

• Measure
• Make a few hypotheses why those things in the profile are slow
• Formulate few solutions to each of the hypotheses
• Try all promising solutions (and observe for more hypotheses)
• Keep the best solution (if there is one)
• Keep the second-best solution around, just in case
• goto 1

In this talk, we’ll demonstrate and explain the principles. We’ll take a basic “Breadth-First Search” implementation and incrementally make it 2x faster on a single core. Then we’ll take these principles to multi-core and squeeze out further 2x. These improvements are accompanied by failures along the way.

The attendees will end up with a clearer understanding of how algorithms are developed and optimized.

Applying Proper Security Practices With JWT

Applying best practices when building your authentication system with JWT, can help minimize or totally eliminate any damage that may occur in the event that your application is compromised. Implementing JWT with proper security practices helps avoid major loopholes that may be harmful to your application. Using JWT for application authentication systems have proven to be very efficient and help save resources. One of the reasons for the popularity of JWT today is the straightforwardness towards its implementation. Many things come for free while implementing authentication with JWT, one of which is the signing algorithm used.

Controlling Distributed Energy Resources with Edge Computing and Go

With advancing technologies, energy distribution model has changed from being centralised to being distributed. We created a platform for distributing and running IoT apps, written in Go, on edge devices to monitor and control distributed energy resources such as photovoltaic and battery systems.

Life of a WireGuard-Go Packet

Yes, you can process network packets in Go efficiently. By following a packet as it moves from the OS to the wireguard-go implementation and back into the OS, we can see how it can be done.

The Go standard library “net” package is surprisingly high-level. Some of the esoteric features needed to make VPNs work require OS-specific workarounds, and the high-level nature of the package can get in the way. This talk lightly touches on some examples of this.

Go Without Generics, a Retrospective

If generics is how we’ll be writing type agnostic code in the future, how are we doing that now?

With the Generics Draft Design making progress, it’s time to look back at the code patterns we needed to do their future job efficiently, today! From interfaces, to reflection and code generation, see the trade offs for each approach to generically handling user types and functions in current Go. See if you recognize these patterns in your own code!

This talk will demonstrate different approaches to executing functions, and methods, along with how that code looks and executes. Benefits and Detriments to each will be discussed, and how they might change with respect to the Generics in Go Draft Design.

The audience will walk away with knowledge of the different existing approaches, and hopefully, a profound sense of excitement for the generics draft design, and what that means for existing Go code.

schedgroup: a Timer-Based Goroutine Concurrency Primitive

Go provides first-class support for concurrency primitives such as goroutines, channels, and select statements. In addition, the Go runtime provides excellent support for high-resolution timers. By combining these primitives, we can create powerful new ones that take advantage of Go’s concurrency and runtime timer facilities.

This talk will introduce a timer-based concurrency primitive called a “schedgroup”: short for “scheduler group”. The schedgroup.Group API mimics the familiar and simple sync.WaitGroup from Go’s standard library. The key feature of the schedgroup.Group type is its ability to efficiently delay or schedule the execution of goroutines according to user-specified time values.

While prototyping the schedgroup package, several different designs were explored, each with differing advantages and disadvantages:

• a minimal implementation which creates a timer per goroutine for scheduling tasks
• a timer-polling approach which checks for scheduled tasks in a queue at a fixed interval
• an event-driven scheduler approach which uses a priority queue and signaling with channels

This talk will demonstrate the strengths and weaknesses of each prototype, building on top of each previous iteration until we reach the final design and implementation of the package as it stands today. During the presentation, attendees will learn about concepts related to Go concurrency and runtime timers, including:

• blocking and non-blocking channel send/receive operations within a select statement
• patterns for implementing context cancelation in concurrent systems
• troubleshooting and prevention of goroutine deadlocks
• efficient use of Go’s time.Timer APIs for tracking elapsed time during operations
• implementing a time-based priority queue with Go’s container/heap package

Why the Prometheus Instrumentation Library is Flawed and What to Do About It

As of writing this, github.com/prometheus/client_golang/prometheus is listed as the 13th most popular package on godoc.org. It has 11,199 known importers according to go.dev. And it has just got honored as one of the top 25 Go Modules by JFrog’s GoCenter.

Despite the success, the package and its sub-packages definitely have a lot of quirks. The speaker is the maintainer of the package and will not only talk about the historical reasons behind a number of the flaws but also about the plans to tackle them. Part of the story is the responsibility of keeping a frequently used piece of software stable and how that results in problems with incrementally improving it. Feature requests that inevitably require a breaking change are currently piled up for a long planned v2 release, and there is a lot of ambition to make it the one more breaking release to end all breaking releases. However, as we all know, perfect is the enemy of good. To find the right balance, the speaker is highly interested in feedback from the audience about the current pain points and the upcoming design decisions.

Better APIs with Shareable Validation Logic

Validating data at various points, like in clients and servers, is desirable. But keeping validation logic in sync between, say Go code and OpenAPI is prone to errors and toil. CUE addresses this issue with the ability to convert and combine various formats. This allows for some cool and exciting rewriting capabilities, such as generating a single documented OpenAPI spec from various sources and automated compatibility checks. It addresses the issue that validation logic can often not be consolidated into one place or format.

The demonstrated abilities are based on experience from the Istio pipeline and the author’s research into composing CRD schemas for Kubernetes.

The talk will demonstrate several conversions, including JSON schema, OpenAPI, and simple tricks in CUE itself.

Writing open source tooling using AST

At Brankas, we needed the ability to define types and GRPC service definitions in a way that made it easier for internal Go developers, this tool became Gunk. Without the AST package, Gunk would have been nearly impossible to build. In this talk, I will be exploring the AST package and how Gunk uses it under the hood to be the amazing tool it is.

Why it takes a team of engineers just to process events in realtime

Data management architectures are changing dramatically. Users and businesses alike have come to expect short feedback loops that require migrating historically batch-based workloads to streaming workloads.

Batch based data pipelines have typically been favored because they’re forgiving in performance and error handling concerns making them easy to write and scale, but have the major downside of having to wait hours or sometimes days to get results. Converting the same insights to streaming workloads introduces new failure modes and availability challenges, but the benefits of the shortened feedback loop lead to faster returns on investment.

Scaling streaming data pipelines is no small feat however. Segment processes hundreds of petabytes of event data per day, exactly once, with reliable processing and delivery but it took a long time and many bright engineers to get here. Come learn from an experienced Go programmer about how to plan, build and maintain these systems and take actionable advice back to your organization to improve your data infrastructure!

Workshop: Bill Kennedy - Web Services in Go

For more information please refer to our Workshops page.

Workshop: Tim Raymond - Introduction to gRPC

For more information please refer to our Workshops page.

Workshop: Eleanor McHugh - An Introduction To Functional Programming In Go

For more information please refer to our Workshops page.